A storage management system manages the allocation prior to use, and release after use, of storage in response to requests from multiple applications running in the same processor. When an application requires some storage to be allocated for its use, it issues a GETMAIN request to the storage management system. The GETMAIN request from the application includes information about the length of storage required. The storage manager responds by informing the application of the address in memory of the storage it has been allocated. When the application no longer requires the allocated storage, it returns it to the storage management system by issuing a FREEMAIN request. The FREEMAIN request from the application includes information about the address in memory of the storage to be released.
Prior art systems use many different algorithms to prevent fragmentation of storage controlled by the system. Requests from an application for storage can be either requests for a fixed length of storage or requests for a variable length of storage. If the requests are for a fixed length of storage then it is relatively simple to use programming techniques which make efficient use of storage.
IBM Technical Disclosure Bulletin "Dynamic Quickcell", November 1973, pp 1999-2004 describes such a programming technique for managing requests for allocation and release of fixed length cells of storage made upon a main storage pool.
In such a system, a pool of storage is divided into generally fixed length cells, known as `quickcells`. Each free quickcell includes a pointer to the next free quickcell in the pool of quickcells. Initially, each quickcell points to the next adjacent one in physical memory address order. After a number of quickcells have been allocated and released the chain of pointers will become unordered in terms of memory addresses. This does not result in any inefficiency when only main storage is employed but when virtual storage is used, inefficiency may result because pointers may point to quickcells in secondary storage.
To overcome this, quickcells may be organized into a continuous page (for example 4096 bytes (4 k)) called a `quickcell page`. Each page of quickcells will always either all be in memory or all paged out onto mass storage. The pointer from each free cell to the next free cell must always be contained within the same page. A number of these quickcell pages are normally arranged together in subpools of storage. A further chain of pointers is created which points from each page having free quickcells to the next such page.
Three common problems arise with the implementation of quickcell pages. These are:
(a) A storage overwrite, where an application writes beyond its allocated storage, which corrupts the pointer in the next free cell in a quickcell page. PA1 (b) A "double freemain" (an attempt to freemain storage which has already been released) within a quickcell subpool, which can result in an infinite loop in the chain of free cells or in a cell being allocated to two different applications. PA1 (c) An "invalid address" provided provided by an application in a freemain request for a quickcell subpool, which can result in storage belonging to another application being released.